Following about a month of irregular activity, I just uploaded three source packages (along with related binary packages, of course) to Debian unstable: gforge (4.5.14-9), gforge-plugin-scmcvs (4.5.14-3), and gforge-plugin-scmsvn (4.5.14-2). I hope unstable will give them more exposure than experimental did. Plans for the future: I ll focus on getting these packages into testing, without too many changes if possible. I haven t managed to get dbconfig-common to work reliably (or at all) with PostgreSQL so far, so I ll consider the migration to its infrastructure as a nice option, but not a blocker. The problem is that it would make the install scripts simpler and (hopefully) more reliable if it worked. Again, help would be very much appreciated. (And yes, I will be submitting bug reports when I get some time to do some more thorough testing of dbconfig-common.)

Welcome to this 2nd issue of the DeFuBu contest, the monthly championship of the funniest bug reported to the Debian BTS. The challengers

• Julien Danjou with #360285 (ITP: libjoey -- forks itself and does several things at the same time), #102434 (gpm: reverse marking) and #178290 (grave problems when badly mixed with irda)
• Pierre Habouzit with #379912 (kodo: Incorrectly described as useless)
• Julien Goodwin with #318229 (XOrg package is controlled by a woman disrespectful of men (which make up the vast majority of debian developers))
• Frans Pop with #258723 (vim: replace $ shlibs:Depends] in debian/control)
• Daniel Burrows with #331210 (aptitude maintainer should do bug DB clean-up and/or bug merging)
• Andres Salomon with #236874 (xscreensaver: pacman screensaver plays game incorrectly)
• Loic Minier with #382014 (can't fly to girlfriend) and #375789 (gnome-osd: information leakage when screensaver is active)
• Florent Bayle with #381978 (debian-installer: etch d-i installs an antique mouse cursor)
• Julien Louis with #382181 (nmap is a clairvoyant)
• Cyril Lacoux with #373142 (apt-get install spamc on testing removes sarge kernel image)

How the vote has been done Five Debian related people voted for these bugs: Roland Mas, Alexis Sukrieh, Cl ment Stenac, kolter and Yves-Alexis Perez. Full ranking Bugs

• #360285 (ITP: libjoey -- forks itself and does several things at the same time) (52 points)
• #102434 (gpm: reverse marking) (44 points)
• #236874 (xscreensaver: pacman screensaver plays game incorrectly) (43 points)
• #258723 (vim: replace $ shlibs:Depends] in debian/control) (37 points)
• #331210 (aptitude maintainer should do bug DB clean-up and/or bug merging) (33 points)
• #382014 (can't fly to girlfriend) (31 points)
• #373142 (apt-get install spamc on testing removes sarge kernel image) (29 points)
• #379912 (kodo: Incorrectly described as useless) and #382181 (nmap is a clairvoyant) (26 points)
• #381978 (debian-installer: etch d-i installs an antique mouse cursor) (15 points)
• #318229 (XOrg package is controlled by a woman disrespectful of men (which make up the vast majority of debian developers)) (22 points)
• #178290 (grave problems when badly mixed with irda) and #375789 (gnome-osd: information leakage when screensaver is active) (13 points)

Challengers

• Julien Danjou (109 points)
• Loic Minier (44 points)
• Andres Salomon (43 points)
• Frans Pop (37 points)
• Daniel Burrows (33 points)
• Cyril Lacoux (29 points)
• Julien Louis and Pierre Habouzit (26 points)
• Julien Goodwin (22 points)
• Florent Bayle (15 points)

The winners

• Bug: #360285 (ITP: libjoey -- forks itself and does several things at the same time)
• Challenger: Julien Danjou
• Bug reporter: Alexander Wirt
• Voter: Roland Mas with the correct reverse ordered tierc : [1] #236874, [2] #102434 and [3] #360285.

Notes To participate, simply drop me an email with a bug number. About DeFuBu

Two small bits: bzr.debian.org and git.d.o now exist both in the DNS and in costa's Apache2 config, so please use them instead of arch.debian.org if you want to do Bzr or Git. Also, work has truly begun on setting up the new host for Alioth. Rapha l has started setting up Xen hosts on wagner.d.o, and I've started reviving my CVS-to-Bazaar gateway for the Gforge code to help us keep our Alioth-specific changes versioned. Along with the move to a faster, bigger box (single box too, so no more account synchronisation delays), we'll take the opportunity to upgrade to Gforge 4.5. We'll keep you posted about that.

A few small things happen on the Alioth front. I mention them as small in comparison to the bigger job of atually migrating to the new box, but they may have some significance to you. bzr support: costa.debian.org AKA svn.d.o AKA arch.d.o can host bzr repositories. The procedure is, as usual, to file a support request asking for the creation of the repository, or nag us on IRC (#alioth). Please allow for 24 hours after the project creation, since the group isn't created on costa straight away; more on that below. Read/write access is done with

bzr checkout sftp://<user>@arch.debian.org/bzr/<group>/whatever

(or bzr branch if you'd like), and anonymous read-only access is

bzr branch http://arch.debian.org/bzr/<group>/whatever

git support: same procedure. Developer checkout becomes

git clone ssh://<user>@costa.debian.org/git/<group>/whatever/.git

and anonymous becomes

git clone http://arch.debian.org/git/<group>/whatever/.git

I'm told there are more efficient ways to do anonymous access, so stay tuned. Update: git-daemon is now installed, and anonymous users can therefore do

git clone git://arch.debian.org/git/<group>/whatever

User/group and authentication data replication: as you may know, the authoritative source for these data is the PostgreSQL database on alioth (haydn.debian.org). From this database, the LDAP tree used for auth on haydn is regenerated every hour, and the PostgreSQL database used for auth on costa is regenerated by a cron.daily script every day at 06:25 UTC. That script takes 10-15 minutes to run, however, during which authentication would be down on costa, because it would first grab the data from haydn, then drop the database, then recreate it with the new and relevant data. It has come to my attention that you can rename databases, though, so the script has been fixed (create gforgenew, then rename gforge to gforgeold and gforgenew to gforge, then drop gforgeold), and the daily downtime should be down to a few seconds at most. As usual, in case of problems, come and see us on IRC, and submit a support request on the siteadmin project. Or mail us at admin@alioth.debian.org. Also, don't forget the Alioth wiki page!

Joey Hess is looking for a tool that allows him to split sets of files across subsets with a known maximal size, for archival on DVD. That sounds a bit like what my ~/bin/prepare-gallery-backups.pl script does. Actually, my script doesn't operate on a per-file granularity, but per-directory (think photo gallery albums), but I suppose it would be rather simple to adapt. Also, there's no guarantee of optimality, and it may well be that you'll end up with a few subsets more than what is strictly needed. I'm not trying to solve the notoriously hard "backpack problem", just looking for a "good enough for me" solution. Now if Joey wants to recode that properly and add it to moreutils, I'll be a happy man. I was about to paste just the relevant excerpt of my script, but since only a few lines would have been omitted, I figured what the hell. Here's the whole script, licensed under a "send me a lot of money if you like, otherwise do what you want" license.

#! /usr/bin/perl
use File::Find ;
$maxsize = 700000 ;
$remote_dir = "/srv/www/gallery.placard.fr.eu.org" ;
$rsync_dir = "/space/backups/gallery-backup/rsync/" ;
$albumsdir = "/space/backups/gallery-backup/rsync/gallery.placard.fr.eu.org/albums" ;
$backupdir = "/space/backups/gallery-backup/backups" ;
# system "rsync -avL --rsh=ssh --delete clodomir:$remote_dir $rsync_dir" ;
system "rsync -avL --rsh=ssh --delete mirobole:$remote_dir $rsync_dir" ;
if ( (defined $ARGV[0])
     && ($ARGV[0] eq "--make-isos") )  
    File::Find::find( wanted => \&wanted, follow => 1 , $albumsdir);
      for $i (@alist)  
    $fname = $i ;
    $fname =~ s,.*/,, ;
    $du = qx/du -hk $i/ ;
    $size = $du ;
    $size =~ s,\s.*,, ;
    $albums $fname size  = $size ;
    $albums $fname path  = $i ;
       
      foreach $album (sort  $albums $b size  <=> $albums $a size  keys %albums)  
    $size = $albums $album size  ;
    $name = $album ;
    $name =~ s,.*/,,;
    if($cur + $size > $maxsize)  
        my @bplist = @curlist ;
        my %entry = ('list' => \@bplist,
             'size' => $cur) ;
        push @backpacks, \%entry ;
        $cur = 0 ;
        @curlist = () ;
     
    $cur += $size ;
    push @curlist, $name ;
       
      my @bplist = @curlist ;
      my %entry = ('list' => \@bplist,
         'size' => $cur) ;
      push @backpacks, \%entry ;
      $i = 1 ;
      foreach $bp (@backpacks)  
    print "Backpack $i (size $bp-> size ) :\n" ;
    $bpdir = $backupdir . "/backup-$i" ;
    system "mkdir -p $bpdir" ;
    foreach $n (@ $bp-> list )  
        print "\t$n\n" ;
        system "cp -a $albumsdir/$n $bpdir/" ;
     
    system "mkisofs -quiet -r -o $backupdir/backup-$i.iso $bpdir" ;
    system "rm -rf $bpdir" ;
    $i++ ;
       
   
sub wanted  
    my ($dev,$ino,$mode,$nlink,$uid,$gid);
    (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_)) ;
    # print "$File::Find::name ; $File::Find::dir\n" ;
    if ((-f $File::Find::name) && ($File::Find::dir eq $albumsdir))  
        # print "Keeping file $File::Find::name\n" ;
        push @alist, "$File::Find::name" ;
     
    if ((-d $File::Find::name) && ($File::Find::dir eq $albumsdir)
      && ($File::Find::name ne $albumsdir))  
        # print "Keeping dir $File::Find::name\n" ;
        push @alist, "$File::Find::name" ;
     
 

...or, "Bits from a Gforge maintainer", if you'd like. After being neglected for way too long, the Gforge packages have finally started moving again. Packages for the most recent upstream release (4.5.14) are available in experimental, with quite a few improvements over the version currently in unstable:

• lots of improvements upstream, of course;
• no more sourceforge transitional package;
• source control management systems are now integrated via plugins rather than core code; existing plugins are gforge-plugin-scmcvs for CVS and -scmsvn for Subversion (both are in experimental);
• should support recent versions of PostgreSQL;
• default authentication scheme for users created through Gforge is now no longer LDAP (although it's still available for the masochistic); nss-pgsql is now preferred, with lots of benefits (not the least being that its configuration and setup are far less brittle);
• and lots more, thanks to Christian Bayle's work while I was busy doing something else.

From a Debian maintainer's point of view, my Gforge-related TODO list now mainly sports three items.

• First, rewrite some PHP code into Perl: the script in charge of bringing the database schema up-to-date, db-upgrade.pl, currently delegates some of its work to PHP scripts with system() calls. That's justifiable by the fact that these PHP scripts can use the Gforge code, classes and methods, but it makes the whole upgrading process fragile: for some reason, the system() calls sometimes fail without db-upgrade.pl noticing, and the process then just goes on with a broken DB instead of stopping right there with an error. Also, this is doomed to fail sometime: the Gforge classes used are the ones currently installed, which may or may not correspond to the database schema (remember we're in the middle of an upgrade, so the schema is moving). Since I want this db-upgrade.pl script to be unbreakable, I need to change that.
• In addition to that (or in parallel), I'd like to migrade the gforge packages to use the dbconfig-common infrastructure. It's supposed to be able to take on the tasks of database (and database user) creation, while still giving me a hook to plug db-upgrade.pl into.
• When the dbconfig-common migration is done, I'll probably spam^Wcontact the various translation teams, so the Debconf templates look good and consistent.

I suppose I could also try and migrate to the webapps-common framework, but I'll keep that for later. Of course, any help is welcome. Remember: the sooner I get the Gforge packages into a reasonable shape, the sooner they'll go to unstable, then testing, and the sooner I'll be backporting them to sarge, which means Alioth can be upgraded. But since I've heard a few complaints about Alioth being too damn slow or broken or whatever, I expect I'll get lots of patches (in bug reports, please) from disgruntled users eager to help.

It's official: I'm going to be on extended unpaid leave from my employer starting on the 22nd of June, for at least a year. I've been a part-time free software freelance for two years and a half, and I think now is a good time to grow that activity. Also, since I was hired almost seven years ago, the company grew (well, "was assimilated" is more like it) from about fifteen people (small start-up) to more than two hundred thousand (France T l com / Orange, you may have heard of them), and the growth pains haven't quite subsided yet. So I hope I'll get a breath of fresh air, at least, in case my venture goes flop and I go back to FT next year. So yeah, I'll be freelancing on everything I can, but my initial focus will probably stay on Gforge, Debian and related topics. Feel free to browse my Gnurandal website and contact me if you're looking for someone. I'm based in France, but if the job can't be done via Internet, I'd be happy to fly to all sorts of places.

Thanks to Lars Wirsenius's mugshots gallery, I finally updated my hackergotchi on Planet Debian to something that doesn't look like a bunch of pixels randomly thrown together. Oh, and wireless net plus a working battery rocks.

Currently sitting next to Josselin Mouette aboard flight AF 434, due to arrive in Mexico in about four hours (and Debconf 6 in Oaxtepec maybe two hours after that). The new battery I recently bought for my laptop means I can type this and not fear being interrupted after a few minutes, and so here I am, re-using the asynchronous blogging system I had set up last year for my world tour. Fond memories come to mind, except that this time I'm reasonably confident there will be network access. And I'm looking forward to hacking all day long for a week. Some of my packages could use some attention. Hm. The only games installed on this laptop are moon-buggy and bastet. I'll have to get a few more in prevision for the return trip.

Lars Wirzenius kindly added some visibility to Kenshi Muto's Debian GNU/Linux hardware compatibility list, and had the interesting idea of mentioning live-cds in the same post. That gave me an idea: why not prepare a minimal live-cd dedicated to hardware compatibility testing? It could automatically open a browser on that check page, try multiple screen resolutions and sound systems and report the results, run glxgears, etc. Just boot on that CD in the computer shop, wait for a few moments, and see in big, easily readable letters, whether a configuration actually works with free software. Don't forget to exclaim loudly if the shop attendant told you it would work and the tests show it doesn't. I'm told there's a tool to automate the creation of live-cds. Any takers for that task?

I am once again the victim of overzealous RSS readers. Especially one called "RSS Popper", which from what I can gather is a plug-in for Outlook. I have no idea how (or even if) it can be configured, but from what I can guess from my logs, it defaults to refresh the RSS feeds every one minute and a half. Which is far too often, especially considering the capacity of my server. Apparently there are only a few people subscribed to my RSS feed using that reader, but when their Outlook is running, my poor old webserver gets noticeably loaded. I am tempted to ban this user-agent from accessing my RSS feeds, but not immediately and without notice though. So if you read this through RSS Popper, please decrease your refresh rate to something reasonable. One refresh every day should be plenty enough. Thanks. Update (2006-02-25): There, it's done. The ban is as restricted as I could make it, but it does affect all users of RSS Popper in aorleans-*.abo.wanadoo.fr, as well as one particular 195.33.x.y address, apparently in Germany.

After large amounts of peer pressure from Rapha l Hertzog and other French Debian Developers, I finally created a new geek-fr category in this blog. The old geek category was renamed to geek-en for consistency, and both are now subcategories of a new geek category. I think that means you'll get articles in both French and English if you just read geek. Same applies for the RSS feeds, so you may like to update your feed readers and aggregators (I already updated Planet Debian). The new geek-fr subcategory will contain articles in French, as you'd expect, and will probably be more related to French-specific events. I'll post another announcement in French in a few minutes.

It seems what I've called my PDA for almost seven years (a Sharp PA-X500) is now dead. Well, it's not quite dead, but apparently the touch-sensitive screen is no longer sensitive to touching, and I'm not aware of any other input device for it. So I'm appealing to my fellow geeks, at least to those of you who know about this kind of things; hear my plea, and please provide some advice. People from Japan, I'm especially eager for your wisdom. First, is there any way I could recover the data that's in it? There's nothing deadly important, it's just to save me the bother of collecting all these phone numbers and addresses again. Some have sentimental value, even if I have totally lost touch with their owners. Before someone suggests deep hackery like removing the memory chip and plugging it into some hand-soldered adaptor then into their old Amstrad, I was more thinking about something infrared, since there's an infrared port. The problem is: can it be activated from outside? I can't switch the thing on the usual way (since the touchscreen is, well, not touchy), I can only get to what's best depicted by this picture of what happens when I remove and re-insert the battery. It's the standard touchscreen calibration tool, from what I understood, but maybe it says somewhere that it can be switched to infrared file-server or so. The manual (in Japanese) mentions Zaurus thingies numerously, but I don't know what they say about them (my Japanese skills are old, and they were never that great anyway). Any idea? Second part, in the very likely case I'm going to replace it: what should I buy? My specs are: stuff the PDA features, I initially bought that as a kanji dictionary, so the replacement needs to have a kanji dictionary too. One where you draw the kanji on the screen, and it recognises it. I'm clueless when it comes to classifying kanji, and if I have to tell the thing that what I'm looking for is something with 17 strokes and the key for "hand", then it loses much of its interest. A kanji→English dictionary would be nice, but not needed. I've managed to cope with kanji→Japanese then Japanese→English. The other, more normal, PDA thingies (addressbook, scheduler, world clock, alarm, etc.) would be nice, but are not compulsory. I don't care about games. I'm going to visit Japan in October, and yes I will spend a couple of hours of Akihabara, but I'd like ideas and opinions beforehand. If someone has an idea for getting the data out but it would require the manual, just say so, I'll bring it along. Why it chose to break down now will stay a mystery. Maximum embarrassment for me because I'll be dictionary-less for a few days in Japan? Or longing for some well-deserved rest since I'm soon going to have the opportunity to replace it? No idea. In any case, it sucks.

I finally took some time to migrate my blog from a (very old) Wordpress to a fairly new Ikiwiki. As I write these lines, the version of Ikiwiki I'm using isn't even released, and it includes two patches made by yours truly (and submitted upstream, of course, as bugs #380680 and #380743), allowing the creation of monthly archives and the possibility of making these archives RSS-less (it doesn't make much sense to have an RSS feed for something that's supposed to be static). The whole blog is now static, since I haven't investigated the comments system. I will probably enable the comments eventually, and I will of course migrate the existing ones (much like I migrated the existing articles, with a combination of a Perl script and some hand-tuning). In the meantime, I'll enjoy a spamless blog. The other regression is the lack of a search facility, but from what I can see it was hardly ever used anyway. Note to readers: old URLs should still work (thanks to Apache's magic mod_rewrite), but please update your bookmarks and feed readers and agregators and so on to use the new ones, since I'll probably disable URLs at some point. Update: I also hacked a new plugin, linkbar.pm, which appends a static Markdown string to all *.mdwn pages before they are rendered. So you should now see the lovely navigation menu on all pages, including the article pages.

Following about a month of irregular activity, I just uploaded three source packages (along with related binary packages, of course) to Debian unstable: gforge (4.5.14-9), gforge-plugin-scmcvs (4.5.14-3), and gforge-plugin-scmsvn (4.5.14-2). I hope unstable will give them more exposure than experimental did. Plans for the future: I’ll focus on getting these packages into testing, without too many changes if possible. I haven’t managed to get dbconfig-common to work reliably (or at all) with PostgreSQL so far, so I’ll consider the migration to its infrastructure as a nice option, but not a blocker. The problem is that it would make the install scripts simpler and (hopefully) more reliable if it worked. Again, help would be very much appreciated. (And yes, I will be submitting bug reports when I get some time to do some more thorough testing of dbconfig-common.)

Joey Hess is looking for a tool that allows him to split sets of files across subsets with a known maximal size, for archival on DVD. That sounds a bit like what my ~/bin/prepare-gallery-backups.pl script does. Actually, my script doesn’t operate on a per-file granularity, but per-directory (think photo gallery albums), but I suppose it would be rather simple to adapt. Also, there’s no guarantee of optimality, and it may well be that you’ll end up with a few subsets more than what is strictly needed. I’m not trying to solve the notoriously hard “backpack problem", just looking for a “good enough for me” solution. Now if Joey wants to recode that properly and add it to moreutils, I’ll be a happy man. I was about to paste just the relevant excerpt of my script, but since only a few lines would have been omitted, I figured what the hell. Here’s the whole script, licensed under a “send me a lot of money if you like, otherwise do what you want” license.

#! /usr/bin/perl use File::Find ; $maxsize = 700000 ;
$remote_dir = "/srv/www/gallery.placard.fr.eu.org" ;
$rsync_dir = "/space/backups/gallery-backup/rsync/" ;
$albumsdir = "/space/backups/gallery-backup/rsync/gallery.placard.fr.eu.org/albums" ;
$backupdir = "/space/backups/gallery-backup/backups" ; # system "rsync -avL --rsh=ssh --delete clodomir:$remote_dir $rsync_dir" ;
system "rsync -avL –rsh=ssh –delete mirobole:$remote_dir $rsync_dir" ; if ( (defined $ARGV[0])
     && ($ARGV[0] eq "–make-isos") )     File::Find::find( wanted => \&wanted, follow => 1 , $albumsdir);
      for $i (@alist)
          $fname = $i ;
          $fname =~ s,.*/,, ;
          $du = qx/du -hk $i/ ;
          $size = $du ;
          $size =~ s,\s.*,, ;
          $albums $fname size = $size ;
          $albums $fname path = $i ;
             foreach $album (sort $albums $b size <=> $albums $a size keys %albums)
          $size = $albums $album size ;
          $name = $album ;
          $name =~ s,.*/,,;
          if($cur + $size > $maxsize)
              my @bplist = @curlist ;
              my %entry = ('list' => \@bplist,
                           'size' => $cur) ;
              push @backpacks, \%entry ;
              $cur = 0 ;
              @curlist = () ;
          
          $cur += $size ;
          push @curlist, $name ;
      
      my @bplist = @curlist ;
      my %entry = ('list' => \@bplist,
                   'size' => $cur) ;
      push @backpacks, \%entry ;       $i = 1 ;
      foreach $bp (@backpacks)
          print "Backpack $i (size $bp-> size ) :\n" ;
          $bpdir = $backupdir . "/backup-$i" ;
          system "mkdir -p $bpdir" ;
          foreach $n (@ $bp-> list )
              print "\t$n\n" ;
              system "cp -a $albumsdir/$n $bpdir/" ;
          
          system "mkisofs -quiet -r -o $backupdir/backup-$i.iso $bpdir" ;
          system "rm -rf $bpdir" ;
          $i++ ;
      
   sub wanted
    my ($dev,$ino,$mode,$nlink,$uid,$gid);     (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_)) ;
# print "$File::Find::name ; $File::Find::dir\n" ;     if ((-f $File::Find::name) && ($File::Find::dir eq $albumsdir))
# print "Keeping file $File::Find::name\n" ;
        push @alist, "$File::Find::name" ;
    
    if ((-d $File::Find::name) && ($File::Find::dir eq $albumsdir)
        && ($File::Find::name ne $albumsdir))
# print "Keeping dir $File::Find::name\n" ;
        push @alist, "$File::Find::name" ;
    


…or, “Bits from a Gforge maintainer", if you’d like. After being neglected for way too long, the Gforge packages have finally started moving again. Packages for the most recent upstream release (4.5.14) are available in experimental, with quite a few improvements over the version currently in unstable:

• lots of improvements upstream, of course;
• no more sourceforge transitional package;
• source control management systems are now integrated via plugins rather than core code; existing plugins are gforge-plugin-scmcvs for CVS and -scmsvn for Subversion (both are in experimental);
• should support recent versions of PostgreSQL;
• default authentication scheme for users created through Gforge is now no longer LDAP (although it’s still available for the masochistic); nss-pgsql is now preferred, with lots of benefits (not the least being that its configuration and setup are far less brittle);
• and lots more, thanks to Christian Bayle’s work while I was busy doing something else.

From a Debian maintainer’s point of view, my Gforge-related TODO list now mainly sports three items.

• First, rewrite some PHP code into Perl: the script in charge of bringing the database schema up-to-date, db-upgrade.pl, currently delegates some of its work to PHP scripts with system() calls. That’s justifiable by the fact that these PHP scripts can use the Gforge code, classes and methods, but it makes the whole upgrading process fragile: for some reason, the system() calls sometimes fail without db-upgrade.pl noticing, and the process then just goes on with a broken DB instead of stopping right there with an error. Also, this is doomed to fail sometime: the Gforge classes used are the ones currently installed, which may or may not correspond to the database schema (remember we’re in the middle of an upgrade, so the schema is moving). Since I want this db-upgrade.pl script to be unbreakable, I need to change that.
• In addition to that (or in parallel), I’d like to migrade the gforge packages to use the dbconfig-common infrastructure. It’s supposed to be able to take on the tasks of database (and database user) creation, while still giving me a hook to plug db-upgrade.pl into.
• When the dbconfig-common migration is done, I’ll probably spam^Wcontact the various translation teams, so the Debconf templates look good and consistent.

I suppose I could also try and migrate to the webapps-common framework, but I’ll keep that for later. Of course, any help is welcome. Remember: the sooner I get the Gforge packages into a reasonable shape, the sooner they’ll go to unstable, then testing, and the sooner I’ll be backporting them to sarge, which means Alioth can be upgraded. But since I’ve heard a few complaints about Alioth being too damn slow or broken or whatever, I expect I’ll get lots of patches (in bug reports, please) from disgruntled users eager to help.

It’s official: I’m going to be on extended unpaid leave from my employer starting on the 22nd of June, for at least a year. I’ve been a part-time free software freelance for two years and a half, and I think now is a good time to grow that activity. Also, since I was hired almost seven years ago, the company grew (well, “was assimilated” is more like it) from about fifteen people (small start-up) to more than two hundred thousand (France T l com / Orange, you may have heard of them), and the growth pains haven’t quite subsided yet. So I hope I’ll get a breath of fresh air, at least, in case my venture goes flop and I go back to FT next year. So yeah, I’ll be freelancing on everything I can, but my initial focus will probably stay on Gforge, Debian and related topics. Feel free to browse my Gnurandal website and contact me if you’re looking for someone. I’m based in France, but if the job can’t be done via Internet, I’d be happy to fly to all sorts of places.

Thanks to Lars Wirsenius’s mugshots gallery, I finally updated my hackergotchi on Planet Debian to something that doesn’t look like a bunch of pixels randomly thrown together. Oh, and wireless net plus a working battery rocks.